The Examiner objected to the specification (Appendix) because a computer 
program listing of more than ten (10) pages was submitted. AppHcant will submit the computer 
program on microfiche when claims have been allowed. Applicant understands that the 
application will not pass to issuance without correction of this problem, and will correct the 
defect as described above. 

The Examiner objected to the drawings as not showing every feature of the 
claimed invention. The Examiner stated that the step flow diagrams lack a recitation of 
determining column widths, they lack a depiction of selecting fonts, and they lack a depiction of 
the claimed screen printing mechanism. Applicant respectfully disagrees. As examples. 
Applicant would like to direct the Examiner's attention to Figure 2, reference numeral 35; Figure 
1, reference numeral 43, Figure 3, reference numeral 125, and Figure 4, reference numeral 243; 
and Figure 3, reference numerals 123 and 137 of the drawings. Other examples exist. 
Withdrawal of this rejection respectfully is requested. 

The Examiner stated that a supplemental oath is required because the application 
presents a claim for subject matter (HTML output) not originally claimed. For the reasons stated 
below with regard to the rejection of claims 44, 56, 80, and 94, AppUcant respectfully disagrees 
and respectfully requests reconsideration. 

The Examiner rejected claims 44, 56, 59, 61, 80, 94, and 110 under 35 U.S.C. § 
112, second paragraph, as containing subject matter which was not described in the specification 
at the time the application was filed. The Examiner found that claims 44, 56, 80, and 94 
represent new matter since Applicant disclosed reformatting HTML documents, but did not 
originally disclose outputting the reformatted documents as HTML, and the reformatted 
document appears to be output in a proprietary format. Applicant respectfully disagrees. As 
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examples, Applicant would like to direct the Examiner's attention to page 24, lines 4-15 of the 
Application. Withdrawal of this rejection respectfully is requested. 

Regarding independent claim 59, the Examiner stated that the process of 
determining a display capability of a window was not described. Applicant respectfully 
disagrees. For example, Applicant would like to direct the Examiner's attention to page 16, lines 
1 1-13 of the Application. Withdrawal of this rejection respectfully is requested. 

Regarding dependent claim 61, the Examiner stated that no support is provided 
for the claimed range of characters per line. Applicant respectfully disagrees. As examples, 
Applicant would like to direct the Examiner's attention to page 6, line 17; page 14, hues 11-18; 
page 18, lines 13-15; and page 26, lines 7-11 of the Application. Withdrawal of this rejection 
respectfully is requested. 

The Examiner rejected claim 42 under 35 U.S.C. § 112, second paragraph, as 
being indefinite for failing to particularly point out and distinctly claim the subject matter which 
Applicant regards as the invention because "the source" lacked antecedent basis. Claim 42 is 
dependent on claim 35. The preamble of claim 35 recites "a soxurce". Thus, antecedent basis is 
correct since "the source" of claim 42 refers back to "a source" identified in the preamble of 
claim 35. Withdrawal of this rejection respectfully is requested. 

The Examiner rejected claims 35-111 under 35 U.S.C. §103(a) as being 
unpatentable over U.S. Patent No. 6,012,071A, issued to Krishna (hereafter "Krishna") in view 
of Wagstaff, Sean, "Future Tense Texture 1.1 Designs Dynamic Pages. (Future Tense's Web 
Authoring Software)(Soflware Review)(Evaluation)," Mac WEEK, Vol. 11, No. 16, pp. P38(l), 
04/1997 (hereafter "Texture 1.1"). 
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It is noted that the Examiner provided a copy of Dyson, Peter E, "Future Tense's 
Texture: slow page viewer mars Powerful Design Tool. (Future Tense Inc.'s Authoring 
Software)(Software Review)(Evaluation)," Seybold Report on Internet Publishing, Vol. 1, No. 1, 
p. 5(4), 09/19967 (hereafter "Texture 1.0"). While the Examiner did not use Texture 1.0 in the 
rejection of the claims, it was cited, and apparently is the same product, different version, as the 
product identified in Texture 1.1. Both Texture 1.0 and Texture 1.1 use the same components to 
build web pages, i.e. a Web Builder using containers, which are then pubUshed for viewing by a 
user using a viewer. Texture 1.1, however, has a few additional functions (i.e. greater speed). 
Thus, the description of Texture 1.1 should be read to include Texture 1.0 (with the exception of 
those additional functions which are readily identifiable), and reasons why the present 
appUcation is patentable over Texture 1.1 apply equally to Texture 1.0. 

Since the same art rejection applies to each of the rejected claims, a description of 
the art references will be provided before handling each claim rejection. It is believed that this 
will assist in the clarification of the art and of the patentable features of the claims. 

Krishna discloses a publishing system having two separate parts — a design and 
layout tool for use in defining electronic publications ("web page builder") and a viewer for use 
in displaying such publications ("viewer"). Using the web page builder, a web page designer 
establishes regions within the electronic publication ("containers") and defines a set of 
instructions for obtaining and formatting information (such as text) to be displayed in each 
region. See column 4, lines 10-18. The web page designer can use a "drag-and-drop" interface 
to select types of containers, such as a rectangle for text, from a palette and drag these containers 
and position them on a work area. The web page designer may rearrange and resize the 
containers and define the characteristics of each container, including size, font, and text flow 
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from column to column in a multicolumn fomiat. See Column 7, lines 55-59 and column 8, lines 
13-17. (Note that the "multi-column format" refers to text flowing from one container to the 
next container, as explained more completely below.) The web page designer may add controls, 
such as a scroll control. Column 7, lines 66-67. The web page designer also may define how to 
respond to user interactions, such as a mouse click, within a region. Once defined, the 
pubUcation is stored as a publication file. See column 4, lines 24-26 and colunm 8, lines 25-30. 

The viewer, in response to a request by a user, accesses and downloads the 
publication file. The viewer arranges that information for display ''as directed by the formatting 
instructions contained within the corresponding region, " (which, as stated above, are set by a 
web page designer using a web page builder). See column 4, lines 10-36. See also column 5, 
lines 58-67; (The viewer may also display the publication using fonts specified by the page 
designer. ... In particular, the design and layout tool allows the page designer to specify the 
fonts that are to be used to render the page or portions thereof). It is instructive that Krishna 
refers to the person using the web page builder as "a page designer" and refers to the person 
using the viewer as "a user." 

The containers display text in a single column. If multiple columns are needed, 
multiple containers are placed by the web page designer on the page. In this manner, text can 
flow from one container to the next. Regardless, the containers, and thus the columns, are set by 
the web page designer using the web page builder. They are not and cannot be dynamically 
calculated by the viewer. They are not and cannot be set by the viewer or based upon any input 
from the user. Thus, the viewer cannot calculate any number of columns and cannot format the 
display page accordingly. 
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It should be noted that Texture 1.0 is an evaluation of a product by a magazine 
writer, not a description of the product by its owner or creator. Thus, the description of Texture 
1.0 in the evaluation is not complete, nor can it safely be said to be accurate. 

Texture 1.0 discloses a publishing system having two separate parts — a design 
and page layout tool used to develop web pages ("web page builder") and a viewer for use in 
displaying such web pages ("viewer"). Using the web page builder, a web page designer defines 
areas of the page within which text and graphics will be drawn ("containers"), and the font and 
the base size of the text for each container is specified. See page 2, paragraphs 1-2. 

Texture 1.0 uses the concept of containers: rectangular fi"ames for text or graphics. 
These containers can be located anywhere on the page, sized and positioned to one pixel 
precision. Text containers can be placed side by side for multi-column pages, or they can be 
stacked vertically to emulate runarounds. See page 2, paragraphs 5-6. The designer can provide 
reader controls for scrolling an oversized image within its container. See page 2, paragraph 8. 

Text containers can be linked in a chain so that text will flow from one to another 
automatically. If scrolling is used, all of the blocks of the chain are scrolled together. The web 
page builder allows the designer to select a display font for the container. See page 2, paragraphs 
10-page 3, paragraph 1. The web page then is saved as a Texture document. 

The Texture document is rendered using the viewer. Thus, what the web page 
designer builds, including the specifications for the containers, is what the reader sees. See page 
3, paragraph 3. 

Text can be scrolled up or down. ScroUing is in increments of a fiiU container 
size. See page 3, paragraph 6. 



6 




It should be noted that Texture 1.1 is an evaluation of a product by a magazine 
writer, not a description of the product by its owner or creator. Thus, the description of Texture 
1.1 in the evaluation is not complete, nor can it safely be said to be accurate. The descriptions of 
Texture 1.0 together with Texture 1.1 more completely describe the product. 

Texture 1.1 discloses a publishing system having two separate parts — a design 
and page layout tool used to create web pages ("web page builder") and a viewer for use in 
displaying such web pages ("viewer"). The web pages are published in a proprietary format that 
is read by the viewer. 

Using the web page builder, a web page designer can set the point size, font color, 
and character spacing of text and other formatting of web pages that viewers will see. See page 

1, paragraph 9 (at bottom of page). The web page designer can create containers side-by-side for 
a multicolumn format. If the text is longer than the box (i.e. container) that the web designer has 
designated for the text, then the web designer can create buttons that lets the viewer scroll up or 
down one screenful at a time (that is one container at a time as described for Texture 1.0). See 
page 2, paragraph 2 (after the heading). Although, it should be noted that if formatted text is 
imported, there is no way to strip the existing formatting and replace it with your own. See page 

2, paragraph 4. Moreover, font effects (selected by a web page designer) will not be seen by all 
web site visitors. See page 2, paragraph 13. 

It is clear from the descriptions of Krishna, Texture 1.0, and Texture 1.1 
(collectively, the "References") that these References do not teach or suggest the inventions of 
Applicant's claims. None of the References teach or suggest generating a source for display 
having a user selected font. In all of the References, the web page designer using a web page 
builder, not the user using the viewer, determines how a source will be displayed and what fonts 
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or other characteristics, including column format, will be used. The user has no control over 
how the source is displayed. Of course, a web page builder would be designed as such so that a 
web page builder can control how the web page looks to all users. Multiple examples have been 
given above with multiple citations to each of the References identifying this. None of the 
References, alone or in combination, teach or suggest this limitation. 

Moreover, none of the References teach or suggest actual non-scroUably 
displaying a source or formatting a source in multiple pages for non-scrollably displaying those 
pages. As explained above, the web page designer uses the web page builder to design a web 
page. The web page designer creates containers having a specified size and location on the web 
page. This container then can be filled with a source text when displayed to the viewer. 
However, when the container is greater than the display page, the user must actually scroll, per 
line or other, through the text in the container. Otherwise, the full text would not be displayed to 
the user. In no event do any of the references teach non-scrollably displaying display pages 
having a user selected font. None of the References, alone or in combination, teach or suggest 
this limitation. 

With regard to the claims requiring a screen page formatting mechanism 
configured to calculate a number of columns that will fit within the screen page, each having a 
width characteristic, and to format the screen page for the number of columns, none of the 
References teach or suggest this limitation. As explained above, the web page designer uses the 
web page builder to build a web page. The web page designer selects a container, such as a 
rectangular container, that ultimately will hold text when displayed to a user. The web page 
designer can put several containers side by side to emulate a multi-column format and format 
each column to direct text to go to the next container. Neither the web page builder nor the 
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viewer calculate anj^hing, much less a number of columns that will fit within the screen page. 
The containers must be physically placed and sized on the web page by the web page designer. 
Nor can the web page builder or the viewer format the screen page as such. Moreover, it should 
be noted that a browser cannot provide these calculating or formatting limitations. Clearly, the 
standard browser identified in Krishna is not capable of doing this, as it does not function in such 
a manner. None of the References, alone or in combination, teach or suggest this limitation. 

Initially, it should be noted for the purposes of all claims herein, a "user" is a 
person or entity viewing the source with the system of the claims, such as a person viewing an 
electronic document with the viewing system. This construction is apparent from the 
specification and the claims. 

The Examiner found that Krishna discloses every limitation of claim 35 except 
that it did not disclose pages that are non-scroUably displayed. The Examiner found that Texture 
1.1 disclosed pages that are non-scrollably displayed. 

Applicant's Claim 35 is directed to a system for generating a source in a non- 
scrolling format for display in a display window. The system requires a screen page formatting 
mechanism and a display page formatting mechanism. The screen page formatting mechanism is 
configured to form a screen page dimensioned to fit the display window, to calculate a nimiber of 
columns that will fit within the screen page, each column having a width characteristic, and to 
format the screen page for the number of columns. The display page formatting mechanism is 
configured to format the source as a display document having a user selected font characteristic 
and a plurality of display pages each non-scrollably displayable for the screen page. 

With regard to the Examiner's rejection, initially it is noted that browsers do not 
calculate any number of columns to fit in a screen page. Browsers communicate using HTTP 
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and merely read standard formatting tags identified in a document, such as HTML tags, and 
display the document according to those tags. Browsers do not fimction as stated by the 
Examiner. Nor does the browser of Krishna function in such a way. The browser of Krishna is 
defined at column 3, lines 8-9 of Krishna, and explained more fiiUy at column 3, Hues 8-40. The 
browser of Krishna is not defined as providing any more capability, such as "calculating a 
number of columns" than is capable with any standard browser. Thus, additionally, the Krishna 
browser cannot format the screen page for the number of columns. For this reason alone, 
withdrawal of the rejection is requested. 

Moreover, Krishna does not teach displaying a document in a user selected font. 
In Krishna, a web page designer creates a web page using containers in which text will be 
placed. (The web page also may contain graphics or others items, such as in other containers.) 
The web page designer selects the size of the container and the font with which the text will be 
formatted in the container. When the user opens the web page, the user has no control over the 
size of the container or the font with which the text is formatted. One of the main reasons of the 
Krishna invention is to send the required font file to the user so the text is formatted accordingly, 
and so that the user cannot use the font file for other purposes. (It is a fiulher object to display an 
electronic publication on a client using fonts specified by the publisher, regardless of whether the 
specified fonts are installed on the client, and to download the fonts only if they are not installed 
on the cHent. Column 3, lines 60-64.) This is stated throughout the Krishna patent. The user 
cannot select a font for which the text will be displayed. Thus, withdrawal of the rejection is 
requested. 

Similarly, the text for the container is not non-scroUably displayed for the 
"display window". As stated, the web page is designed by the web page-designer. The container 
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can be sized such that the web page designer can view the container and put text in the container 
so that it displays on a full screen. However, if a user opens that page for display in a "display 
window", the container may not fit the window and would not be non-scrollably displayed. For 
example, the user may open the web page for display on a display window smaller than the full 
size of the monitor. Then, the container is larger than the display window, and the text cannot be 
non-scrollably displayed. The user would have to scroll to the bottom of the container using a 
conventional scroll bar or down arrow key and could thereafter "page" to the next screen. A 
similar situation will occur when a web page with a container is set for a specified size monitor, 
and the monitor is smaller than that specified size. Thus, withdrawal of the rejection is 
requested. 

As explained above, neither Texture 1.1 nor Texture 1.0 teach or suggest the 
above-described items. Thus, neither Texture 1.1 nor Texture 1.0 teach or suggest a screen page 
formatting mechanism configured to calculate a number of columns that will fit within the screen 
page, each column having a width characteristic, and to format the screen page for the number of 
columns. Also, neither Texture 1.1 nor Texture 1.0 teach or suggest a display page formatting 
mechanism configured to format the source as a display document having a user selected font 
characteristic. Moreover, neither Texture 1.1 nor Texture 1.0 teach or suggest a display page 
formatting mechanism configured to format the source as a display document having display 
pages each non-scrollably displayable for the screen page, especially not with the user selected 
font characteristic 

Krishna does not disclose, teach, or suggest the system of Applicant's claim 35. 
Neither Texture 1.1 nor Texture 1.0 supply the deficiencies of Krishna. 
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Neither Krishna nor Texture 1.1 (nor Texture 1.0), whether considered separately 
or in any combination, disclose, teach, or suggest the system of Applicant's claim 35. Therefore, 
Applicant submits that claim 35 is allowable. Withdrawal of the rejection respectfully is 
requested. 

Claims 36-49 depend directly or indirectly from claim 35. Since these dependent 
claims include all of the limitations of the base claim, which has been shown to be allowable 
over the cited references and other references of record. Applicant submits that these claims also 
are allowable. Withdrawal of the rejection of claims 36-49 respectfully is requested. 

With regard to Applicant's claim 35, Krishna does not teach displaying a 
document in a user selected font. In Krishna, a web page designer creates a web page using 
containers in which text will be placed. (The web page also may contain graphics or others 
items, such as in other containers.) The web page designer selects the size of the container and 
the font with which the text will be formatted in the container. When the user opens the web 
page, the user has no control over the size of the container or the font with which the text is 
formatted. One of the main reasons of the Krishna invention is to send the required font file to 
the user so the text is formatted accordingly, and so that the user cannot use the font file for other 
purposes. (It is a further object to display an electronic publication on a client using fonts 
specified by the publisher, regardless of whether the specified fonts are installed on the client, 
and to download the fonts only if they are not installed on the client. Column 3, lines 60-64.) 
This is stated throughout the Krishna patent. The user cannot select a font for which the text will 
be displayed. Thus, withdrawal of the rejection is requested. 

Similarly, the text for the container is not non-scroUably displayed for the 
"display window". As stated, the web page is designed by the web page designer. The container 
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can be sized such that the web page designer can view the container and put text in the container 
so that it displays on a full screen. However, if a user opens that page for display in a "display 
window", the container may not fit the window and would not be non-scrollably displayed. For 
example, the user may open the web page for display on a display window smaller than the full 
size of the monitor. Then, the container is larger than the display window, and the text cannot be 
non-scrollably displayed. The user would have to scroll to the bottom of the container using a 
conventional scroll bar or down arrow key and could thereafter "page" to the next screen. A 
similar situation will occur when a web page with a container is set for a specified size monitor, 
and the monitor is smaller than that specified size. Thus, withdrawal of the rejection is 
requested. 

As explained above, neither Texture 1.1 nor Texture 1.0 teach or suggest the 
above-described items. Thus, neither Texture 1.1 nor Texture 1.0 teach or suggest a screen page 
formatting mechanism configured to calculate a number of columns that will fit within the screen 
page, each column having a width characteristic, and to format the screen page for the number of 
columns. Also, neither Texture 1.1 nor Texture 1.0 teach or suggest a display page formatting 
mechanism configured to format the source as a display document having a user selected font 
characteristic. Moreover, neither Texture 1.1 nor Texture 1.0 teach or suggest a display page 
formatting mechanism configured to format the source as a display document having display 
pages each non-scrollably displayable for the screen page, especially not with the user selected 
font characteristic 

Krishna does not disclose, teach, or suggest the system of Applicant's claim 50. 
Neither Texture 1.1 nor Texture 1.0 supply the deficiencies of Krishna. 
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Neither Krishna nor Texture 1.1 (nor Texture 1.0), whether considered separately 
or in any combination, disclose, teach, or suggest the system of Applicant's claim 50. Therefore, 
Applicant submits that claim 50 is allowable. Withdrawal of the rejection respectfully is 
requested. 

Claims 51-57 depend directly or indirectly from claim 35. Since these dependent 
claims include all of the limitations of the base claim, which has been shown to be allowable 
over the cited references and other references of record. Applicant submits that these claims also 
are allowable. Withdrawal of the rejection of claims 36-49 respectfully is requested. 

Applicant's independent claim 58 is believed to be patentable for the same 
reasons as claim 50. Additionally, a screen page cannot be filled with at least one display page 
since a plurality of display pages cannot be non-scroUably displayed. Neither Krishna nor 
Texture 1.1 (nor Texture 1.0), whether considered separately or in any combination, disclose, 
teach, or suggest the system of Applicant's claim 58. Therefore, Applicant submits that claim 58 
is allowable. Withdrawal of the rejection respectfully is requested. 

Claims 59-84 depend directly or indirectly from claim 58. Since these dependent 
claims include all of the limitations of the base claim, which has been shown to be allowable 
over the cited references and other references of record. Applicant submits that these claims also 
are allowable. Withdrawal of the rejection of claims 59-84 respectfully is requested. 

Applicant's independent claim 85 is believed to be patentable for the same 
reasons as claim 35. Withdrawal of the rejection respectfully is requested. 

Claims 86-87 depend directly or indirectly from claim 85. Since these dependent 
claims include all of the limitations of the base claim, which has been shown to be allowable 
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over the cited references and other references of record, AppUcant submits that these claims also 
are allowable. Withdrawal of the rejection of claims 86-87 respectfully is requested. 

Regarding Applicant's claim 88, Krishna does not teach sizing electronic 
information to a user selected font. In Krishna, a web page designer creates a web page using 
containers in which text will be placed. (The web page also may contain graphics or others 
items, such as in other containers.) The web page designer selects the size of the container and 
the font with which the text will be formatted in the container. When the user opens the web 
page, the user has no control over the size of the container or the font with which the text is 
formatted. One of the main reasons of the Krishna invention is to send the required font file to 
the user so the text is formatted accordingly, and so that the user cannot use the font file for other 
purposes. (It is a further object to display an electronic publication on a client using fonts 
specified by the publisher, regardless of whether the specified fonts are installed on the client, 
and to download the fonts only if they are not installed on the client. Column 3, lines 60-64.) 
This is stated throughout the Krishna patent. The user cannot select a font for which the text will 
be displayed. Thus, withdrawal of the rejection is requested. 

Similarly, Krishna does not teach or suggest formatting the electronic information 
to form a display document having display pages wherein each display page is wholly 
displayable in the screen display and at least one display page is not generated for non-scrollable 
display. As stated, the web page is designed by the web page designer. The container can be 
sized such that the web page designer can view the container and put text in the container so that 
it displays on a full screen. However, if a user opens that page for display in a "display 
window", the container may not fit the window and would not be non-scroUably displayed. For 
example, the user may open the web page for display on a display window smaller than the full 
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size of the monitor. Then, the container is larger than the display window, and the text cannot be 
non-scroUably displayed. The user would have to scroll to the bottom of the container using a 
conventional scroll bar or down arrow key and could thereafter "page" to the next screen. A 
similar situation will occur when a web page with a container is set for a specified size monitor, 
and the monitor is smaller than that specified size. Thus, withdrawal of the rejection is 
requested. 

As explained above, neither Texture 1.1 nor Texture 1.0 teach or suggest the 
above-described items. Thus, neither Texture 1.1 nor Texture 1.0 teach or suggest a screen page 
formatting mechanism configured to calculate a number of columns that will fit within the screen 
page, each column having a width characteristic, and to format the screen page for the number of 
columns. Also, neither Texture 1.1 nor Texture 1.0 teach or suggest a display page formatting 
mechanism configured to format the source as a display document having a user selected font 
characteristic. Moreover, neither Texture 1.1 nor Texture 1.0 teach or suggest a display page 
formatting mechanism configured to format the source as a display document having display 
pages each non-scroUably displayable for the screen page, especially not with the user selected 
font characteristic 

Krishna does not disclose, teach, or suggest the system of Applicant's claim 50. 
Neither Texture 1.1 nor Textm-e 1.0 supply the deficiencies of Krishna. 

Neither Krishna nor Texture 1.1 (nor Texture 1.0), whether considered separately 
or in any combination, disclose, teach, or suggest the system of Applicant's claim 88. Therefore, 
Applicant submits that claim 88 is allowable. Withdrawal of the rejection respectfiiUy is 
requested. 
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Claims 89-95 depend directly or indirectly from claim 88. Since these dependent 
claims include all of the limitations of the base claim, which has been shown to be allowable 
over the cited references and other references of record, Applicant submits that these claims also 
are allowable. Withdrawal of the rejection of claims 89-95 respectfully is requested. 

Applicant's independent claim 96 is believed to be patentable for the same 
reasons as claim 50. Withdrawal of the rejection respectfully is requested. 

Claims 97-103 depend directly or indirectly from claim 96. Since these 
dependent claims include all of the limitations of the base claim, which has been shovra to be 
allowable over the cited references and other references of record. Applicant submits that these 
claims also are allowable. Withdrawal of the rejection of claims 97-103 respectfully is 
requested. 

Applicant's independent claim 104 is believed to be patentable for the same 
reasons as claim 58. Withdrawal of the rejection respectfully is requested. 

Claims 105-111 depend directly or indirectly from claim 96. Since these 
dependent claims include all of the limitations of the base claim, which has been shown to be 
allowable over the cited references and other references of record, Applicant submits that these 
claims also are allowable. Withdrawal of the rejection of claims 105-111 respectfully is 
requested. 

Applicant has reviewed the Remarks made by the Examiner in the Remarks 
portion of the Office action. Applicant has reviewed the references cited in the Remarks section' 
of the Office action and believes that the claims are allowable over those references and the 
references cited above, whether considered separated or in any combination. 
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The references cited by the Examiner and made of record have been reviewed by 
Apphcant, Applicant has no further remarks with regard to those references. 

Based on the foregoing, it is submitted that the AppUcant's invention as defined 
by the claims is patentable over the references of record. Issuance of a Notice of Allowance is 
solicited. 



Examiner in the event that there are any questions or comments regarding the response or the 
application. 



Applicant's attorney welcomes the opportunity to discuss the case with the 



This is intended to be a complete response to the Examiner's Office action mailed 



on April 11,2001. 
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